1. Field of the Invention
The invention relates to methods and apparatus for testing computer programs. More particularly, the invention relates to methods and apparatus for environment based data driven testing of computer programs which have a graphical user interface (GUI).
2. Brief Description of the Prior Art
Computer programs consist of lines of individual instructions that are read and executed by a processor. Early computer programs were not “interactive”. They consisted of a set of instructions that were designed to be read and executed starting with the first instruction and ending with a last instruction. If one of the instructions contained an error, the processor would halt the program when it tried to execute the defective instruction. The programmer would then need to review all of the instructions to determine which one was defective. Although this task of manually “de-bugging” a computer program was tedious, it was possible because early computer programs were relatively short.
As computer programs grew in length and complexity, automated de-bugging tools became necessary. An early de-bugging tool would simply identify which instruction caused the program to halt. This was generally sufficient for debugging a simple linear program, but in the case of looping programs, an instruction might function in some modes and malfunction in other modes.
Today, even “simple” computer programs are very large, often consisting of millions of instructions. Moreover, most of today's computer programs are “interactive”, i.e. require interaction with the user of the program. Thus, a defective instruction in the program might only be discovered in the case of a particular user action. Furthermore, most of today's computer programs have a graphical user interface (GUI). A GUI typically includes various elements, referred to as “objects”, including “windows”, “menus”, “icons”, “dialog boxes”, “lists”, “radio buttons”, “check boxes”, “text entry fields”, etc. De-bugging a program that has a GUI is doubly complex because, in addition to the instructions for the program to carry out computing tasks, the program also includes instructions for managing the GUI.
There are several known testing tools for de-bugging GUI applications. One such tool is WinRunner® from Mercury Interactive Corporation, Sunnyvale, Calif. WinRunner® is a testing tool which verifies that GUI applications work as expected. By capturing, verifying and replaying user interactions automatically, WinRunner® identifies defects in multiple processes.
With WinRunner®, tests are created by recording user actions. As a test is recorded, check-points are created to compare expected outcomes with actual outcomes. Each time a test is recorded, a GUI map is created. The GUI map contains a list of all of the objects and object attributes used by the test. Each test is recorded using an editable test scripting language (TSL).
A disadvantage of most GUI testing tools, including WinRunner®, is that a separate test script must be created for each GUI application feature. Several thousand test cases (or steps) have to be executed manually with manual and/or visual verification of test results. Repetitive manual execution of test cases is required in order to verify correction of faults or to re-verify functionality of an application after any new production of the application under test. Record and replay operations for generating repeatable test cases require test script (code) modifications for each error found or new test case identified. The modifications themselves require thorough testing before the actual test result quality can be assured. New objects or fields that are added to the GUI application or objects that are moved or removed have a significant impact on all previously recorded test cases even though the behavior of the application has not changed.
Generally, the principles of data driven testing in the prior art include data for automatic test execution according to preprogrammed sequences. However, the data provided to drive the testing does not include data that can be used to define the environment. Taken together, the environment and associated behavior of GUI objects in that environment require specific code or test scripts to be generated and tested. New applications or modifications to an existing application under test cannot be implemented without significant test software development. A significant investment in manpower is required to implement, maintain and enhance the test software that is not reusable.